Microsoft SQL SERVER is a comprehensive database management platform that provides extensive management and development tools, a powerful extraction, transformation, and loading (ETL) tool, business intelligence and analysis services, and other capabilities. Among other improvements, the Microsoft Windows .NET Framework Common Language Runtime (CLR) has been recently integrated into the SQL SERVER database.
The CLR is the heart of the Microsoft .NET Framework, and provides the execution environment for all .NET code. Code that runs within the CLR is referred to as “managed code.” The CLR provides various functions and services required for program execution, including just-in-time (JIT) compilation, allocating and managing memory, enforcing type safety, exception handling, thread management and security. The CLR is now loaded by SQL SERVER upon the first invocation of a .NET routine.
In previous versions of SQL SERVER, database programmers were limited to using Transact-SQL (T-SQL) when writing code on the server side. T-SQL is an extension of SQL as defined by the International Standards Organization (ISO) and the American National Standards Institute (ANSI). Using T-SQL, database developers can create, modify and delete databases, tables and other objects, as well as insert, retrieve, modify and delete data stored in a database. T-SQL is specifically designed for direct declarative data access and manipulation. While T-SQL excels at structural data access and management, it is not as capable as languages such as Visual Basic .NET and C#. For example, T-SQL does not support arrays, collections, for each loops, bit shifting or classes.
With the CLR integrated into the SQL SERVER database, database developers can now perform tasks that were difficult or even impossible to achieve with T-SQL alone. Both Visual Basic .NET and C# are modern programming languages offering full support for arrays, structured exception handling, and collections. Developers can leverage CLR integration to write code that has more complex logic and is more suited for computational tasks using languages such as Visual Basic .NET and C#.
As is the case with any type of software code, debugging is an essential step in assuring that the code operates as intended, and without errors. Unfortunately, existing T-SQL debugging architectures have shortcomings that adversely affect the development experience. For example, existing T-SQL debugging architectures require the involvement of the client driver during the setup of debugging. As a result, only applications using drivers specifically designed for T-SQL debugging can be debugged. Thus, Simple Object Access Protocol (SOAP) connections over HyperText Transfer Protocol (HTTP), and connections using drivers that do not account for T-SQL debugging, cannot be accessed by the debugger.
A further shortcoming of an existing debugger is such a debugger's limited functionality. For example, an existing debugger is limited to debugging persisted T-SQL stack frames, because the debugger cannot debug dynamic, non-persisted T-SQL stack frames. In addition, conventional debuggers are not able to switch between debugging T-SQL and managed code that operates within the CLR. With the integration of the CLR into the SQL SERVER database, such a shortcoming adversely affects the development environment. Furthermore, existing debuggers do not limit the user interface display of activity on the server to the managed code connection being debugged. As a result, a developer is overwhelmed with information from all threads, many of which may be irrelevant to the developer's debugging task at hand.
Accordingly, what is needed is a debugging architecture that addresses the limitations and shortcomings addressed above. More particularly, what is needed is a debugging architecture that is independent from the client driver, and therefore independent from the client protocol, thereby enabling debugging of server activity related to any SQL SERVER client connection. Even more particularly, what is needed is an architecture that enables debugging of dynamic T-SQL stack frames, as well as both T-SQL and managed code, by way of a user interface that only displays the activity within the server on the connection being debugged.